
%% bare_conf.tex
%% V1.3
%% 2007/01/11
%% by Michael Shell
%% See:
%% http://www.michaelshell.org/
%% for current contact information.
%%
%% This is a skeleton file demonstrating the use of IEEEtran.cls
%% (requires IEEEtran.cls version 1.7 or later) with an IEEE conference paper.
%%
%% Support sites:
%% http://www.michaelshell.org/tex/ieeetran/
%% http://www.ctan.org/tex-archive/macros/latex/contrib/IEEEtran/
%% and
%% http://www.ieee.org/

%%*************************************************************************
%% Legal Notice:
%% This code is offered as-is without any warranty either expressed or
%% implied; without even the implied warranty of MERCHANTABILITY or
%% FITNESS FOR A PARTICULAR PURPOSE! 
%% User assumes all risk.
%% In no event shall IEEE or any contributor to this code be liable for
%% any damages or losses, including, but not limited to, incidental,
%% consequential, or any other damages, resulting from the use or misuse
%% of any information contained here.
%%
%% All comments are the opinions of their respective authors and are not
%% necessarily endorsed by the IEEE.
%%
%% This work is distributed under the LaTeX Project Public License (LPPL)
%% ( http://www.latex-project.org/ ) version 1.3, and may be freely used,
%% distributed and modified. A copy of the LPPL, version 1.3, is included
%% in the base LaTeX documentation of all distributions of LaTeX released
%% 2003/12/01 or later.
%% Retain all contribution notices and credits.
%% ** Modified files should be clearly indicated as such, including  **
%% ** renaming them and changing author support contact information. **
%%
%% File list of work: IEEEtran.cls, IEEEtran_HOWTO.pdf, bare_adv.tex,
%%                    bare_conf.tex, bare_jrnl.tex, bare_jrnl_compsoc.tex
%%*************************************************************************

% *** Authors should verify (and, if needed, correct) their LaTeX system  ***
% *** with the testflow diagnostic prior to trusting their LaTeX platform ***
% *** with production work. IEEE's font choices can trigger bugs that do  ***
% *** not appear when using other class files.                            ***
% The testflow support page is at:
% http://www.michaelshell.org/tex/testflow/



% Note that the a4paper option is mainly intended so that authors in
% countries using A4 can easily print to A4 and see how their papers will
% look in print - the typesetting of the document will not typically be
% affected with changes in paper size (but the bottom and side margins will).
% Use the testflow package mentioned above to verify correct handling of
% both paper sizes by the user's LaTeX system.
%
% Also note that the "draftcls" or "draftclsnofoot", not "draft", option
% should be used if it is desired that the figures are to be displayed in
% draft mode.
%
\documentclass[10pt, a4paper, conference, compsocconf]{IEEEtran}
% Add the compsocconf option for Computer Society conferences.
%
% If IEEEtran.cls has not been installed into the LaTeX system files,
% manually specify the path to it like:
% \documentclass[conference]{../sty/IEEEtran}


\usepackage{graphicx}
\usepackage{url}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}

% Some very useful LaTeX packages include:
% (uncomment the ones you want to load)


% *** MISC UTILITY PACKAGES ***
%
%\usepackage{ifpdf}
% Heiko Oberdiek's ifpdf.sty is very useful if you need conditional
% compilation based on whether the output is pdf or dvi.
% usage:
% \ifpdf
%   % pdf code
% \else
%   % dvi code
% \fi
% The latest version of ifpdf.sty can be obtained from:
% http://www.ctan.org/tex-archive/macros/latex/contrib/oberdiek/
% Also, note that IEEEtran.cls V1.7 and later provides a builtin
% \ifCLASSINFOpdf conditional that works the same way.
% When switching from latex to pdflatex and vice-versa, the compiler may
% have to be run twice to clear warning/error messages.






% *** CITATION PACKAGES ***
%
%\usepackage{cite}
% cite.sty was written by Donald Arseneau
% V1.6 and later of IEEEtran pre-defines the format of the cite.sty package
% \cite{} output to follow that of IEEE. Loading the cite package will
% result in citation numbers being automatically sorted and properly
% "compressed/ranged". e.g., [1], [9], [2], [7], [5], [6] without using
% cite.sty will become [1], [2], [5]--[7], [9] using cite.sty. cite.sty's
% \cite will automatically add leading space, if needed. Use cite.sty's
% noadjust option (cite.sty V3.8 and later) if you want to turn this off.
% cite.sty is already installed on most LaTeX systems. Be sure and use
% version 4.0 (2003-05-27) and later if using hyperref.sty. cite.sty does
% not currently provide for hyperlinked citations.
% The latest version can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/cite/
% The documentation is contained in the cite.sty file itself.






% *** GRAPHICS RELATED PACKAGES ***
%
\ifCLASSINFOpdf
  % \usepackage[pdftex]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../pdf/}{../jpeg/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.pdf,.jpeg,.png}
\else
  % or other class option (dvipsone, dvipdf, if not using dvips). graphicx
  % will default to the driver specified in the system graphics.cfg if no
  % driver is specified.
  % \usepackage[dvips]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../eps/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.eps}
\fi
% graphicx was written by David Carlisle and Sebastian Rahtz. It is
% required if you want graphics, photos, etc. graphicx.sty is already
% installed on most LaTeX systems. The latest version and documentation can
% be obtained at: 
% http://www.ctan.org/tex-archive/macros/latex/required/graphics/
% Another good source of documentation is "Using Imported Graphics in
% LaTeX2e" by Keith Reckdahl which can be found as epslatex.ps or
% epslatex.pdf at: http://www.ctan.org/tex-archive/info/
%
% latex, and pdflatex in dvi mode, support graphics in encapsulated
% postscript (.eps) format. pdflatex in pdf mode supports graphics
% in .pdf, .jpeg, .png and .mps (metapost) formats. Users should ensure
% that all non-photo figures use a vector format (.eps, .pdf, .mps) and
% not a bitmapped formats (.jpeg, .png). IEEE frowns on bitmapped formats
% which can result in "jaggedy"/blurry rendering of lines and letters as
% well as large increases in file sizes.
%
% You can find documentation about the pdfTeX application at:
% http://www.tug.org/applications/pdftex





% *** MATH PACKAGES ***
%
%\usepackage[cmex10]{amsmath}
% A popular package from the American Mathematical Society that provides
% many useful and powerful commands for dealing with mathematics. If using
% it, be sure to load this package with the cmex10 option to ensure that
% only type 1 fonts will utilized at all point sizes. Without this option,
% it is possible that some math symbols, particularly those within
% footnotes, will be rendered in bitmap form which will result in a
% document that can not be IEEE Xplore compliant!
%
% Also, note that the amsmath package sets \interdisplaylinepenalty to 10000
% thus preventing page breaks from occurring within multiline equations. Use:
%\interdisplaylinepenalty=2500
% after loading amsmath to restore such page breaks as IEEEtran.cls normally
% does. amsmath.sty is already installed on most LaTeX systems. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/amslatex/math/





% *** SPECIALIZED LIST PACKAGES ***
%
%\usepackage{algorithmic}
% algorithmic.sty was written by Peter Williams and Rogerio Brito.
% This package provides an algorithmic environment fo describing algorithms.
% You can use the algorithmic environment in-text or within a figure
% environment to provide for a floating algorithm. Do NOT use the algorithm
% floating environment provided by algorithm.sty (by the same authors) or
% algorithm2e.sty (by Christophe Fiorio) as IEEE does not use dedicated
% algorithm float types and packages that provide these will not provide
% correct IEEE style captions. The latest version and documentation of
% algorithmic.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithms/
% There is also a support site at:
% http://algorithms.berlios.de/index.html
% Also of interest may be the (relatively newer and more customizable)
% algorithmicx.sty package by Szasz Janos:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithmicx/




% *** ALIGNMENT PACKAGES ***
%
%\usepackage{array}
% Frank Mittelbach's and David Carlisle's array.sty patches and improves
% the standard LaTeX2e array and tabular environments to provide better
% appearance and additional user controls. As the default LaTeX2e table
% generation code is lacking to the point of almost being broken with
% respect to the quality of the end results, all users are strongly
% advised to use an enhanced (at the very least that provided by array.sty)
% set of table tools. array.sty is already installed on most systems. The
% latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/tools/


%\usepackage{mdwmath}
%\usepackage{mdwtab}
% Also highly recommended is Mark Wooding's extremely powerful MDW tools,
% especially mdwmath.sty and mdwtab.sty which are used to format equations
% and tables, respectively. The MDWtools set is already installed on most
% LaTeX systems. The lastest version and documentation is available at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/mdwtools/


% IEEEtran contains the IEEEeqnarray family of commands that can be used to
% generate multiline equations as well as matrices, tables, etc., of high
% quality.


%\usepackage{eqparbox}
% Also of notable interest is Scott Pakin's eqparbox package for creating
% (automatically sized) equal width boxes - aka "natural width parboxes".
% Available at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/eqparbox/





% *** SUBFIGURE PACKAGES ***
%\usepackage[tight,footnotesize]{subfigure}
% subfigure.sty was written by Steven Douglas Cochran. This package makes it
% easy to put subfigures in your figures. e.g., "Figure 1a and 1b". For IEEE
% work, it is a good idea to load it with the tight package option to reduce
% the amount of white space around the subfigures. subfigure.sty is already
% installed on most LaTeX systems. The latest version and documentation can
% be obtained at:
% http://www.ctan.org/tex-archive/obsolete/macros/latex/contrib/subfigure/
% subfigure.sty has been superceeded by subfig.sty.



%\usepackage[caption=false]{caption}
%\usepackage[font=footnotesize]{subfig}
% subfig.sty, also written by Steven Douglas Cochran, is the modern
% replacement for subfigure.sty. However, subfig.sty requires and
% automatically loads Axel Sommerfeldt's caption.sty which will override
% IEEEtran.cls handling of captions and this will result in nonIEEE style
% figure/table captions. To prevent this problem, be sure and preload
% caption.sty with its "caption=false" package option. This is will preserve
% IEEEtran.cls handing of captions. Version 1.3 (2005/06/28) and later 
% (recommended due to many improvements over 1.2) of subfig.sty supports
% the caption=false option directly:
%\usepackage[caption=false,font=footnotesize]{subfig}
%
% The latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/subfig/
% The latest version and documentation of caption.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/caption/




% *** FLOAT PACKAGES ***
%
%\usepackage{fixltx2e}
% fixltx2e, the successor to the earlier fix2col.sty, was written by
% Frank Mittelbach and David Carlisle. This package corrects a few problems
% in the LaTeX2e kernel, the most notable of which is that in current
% LaTeX2e releases, the ordering of single and double column floats is not
% guaranteed to be preserved. Thus, an unpatched LaTeX2e can allow a
% single column figure to be placed prior to an earlier double column
% figure. The latest version and documentation can be found at:
% http://www.ctan.org/tex-archive/macros/latex/base/



%\usepackage{stfloats}
% stfloats.sty was written by Sigitas Tolusis. This package gives LaTeX2e
% the ability to do double column floats at the bottom of the page as well
% as the top. (e.g., "\begin{figure*}[!b]" is not normally possible in
% LaTeX2e). It also provides a command:
%\fnbelowfloat
% to enable the placement of footnotes below bottom floats (the standard
% LaTeX2e kernel puts them above bottom floats). This is an invasive package
% which rewrites many portions of the LaTeX2e float routines. It may not work
% with other packages that modify the LaTeX2e float routines. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/sttools/
% Documentation is contained in the stfloats.sty comments as well as in the
% presfull.pdf file. Do not use the stfloats baselinefloat ability as IEEE
% does not allow \baselineskip to stretch. Authors submitting work to the
% IEEE should note that IEEE rarely uses double column equations and
% that authors should try to avoid such use. Do not be tempted to use the
% cuted.sty or midfloat.sty packages (also by Sigitas Tolusis) as IEEE does
% not format its papers in such ways.





% *** PDF, URL AND HYPERLINK PACKAGES ***
%
%\usepackage{url}
% url.sty was written by Donald Arseneau. It provides better support for
% handling and breaking URLs. url.sty is already installed on most LaTeX
% systems. The latest version can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/misc/
% Read the url.sty source comments for usage information. Basically,
% \url{my_url_here}.





% *** Do not adjust lengths that control margins, column widths, etc. ***
% *** Do not use packages that alter fonts (such as pslatex).         ***
% There should be no need to do such things with IEEEtran.cls V1.6 and later.
% (Unless specifically asked to do so by the journal or conference you plan
% to submit to, of course. )


% correct bad hyphenation here
\hyphenation{op-tical net-works semi-conduc-tor}


\begin{document}
%
% paper title
% can use linebreaks \\ within to get better formatting as desired
\title{Storage policy in a Federated Cloud Infraestructure for Bionformatics
Applications}


% author names and affiliations
% use a multiple column layout for up to two different
% affiliations

\author{\IEEEauthorblockN{Breno R. Moura, Deric L. Bacelar, Edward Ribeiro, Alet\'ia P. F.
Ara\'ujo,  Maristela T. Holanda and Maria E. M. T. Walter}
\IEEEauthorblockA{Department of Computer Science University of Brasilia, UNB,
Brazil\\
\{mourabreno, dericlima, edward.ribeiro\}@gmail.com,
\{aleteia, mholanda, mia\}@cic.unb.br}

}
% conference papers do not typically use \thanks and this command
% is locked out in conference mode. If really needed, such as for
% the acknowledgment of grants, issue a \IEEEoverridecommandlockouts
% after \documentclass

% for over three affiliations, or if they all won't fit within the width
% of the page, use this alternative format:
% 
%\author{\IEEEauthorblockN{Michael Shell\IEEEauthorrefmark{1},
%Homer Simpson\IEEEauthorrefmark{2},
%James Kirk\IEEEauthorrefmark{3}, 
%Montgomery Scott\IEEEauthorrefmark{3} and
%Eldon Tyrell\IEEEauthorrefmark{4}}
%\IEEEauthorblockA{\IEEEauthorrefmark{1}School of Electrical and Computer Engineering\\
%Georgia Institute of Technology,
%Atlanta, Georgia 30332--0250\\ Email: see http://www.michaelshell.org/contact.html}
%\IEEEauthorblockA{\IEEEauthorrefmark{2}Twentieth Century Fox, Springfield, USA\\
%Email: homer@thesimpsons.com}
%\IEEEauthorblockA{\IEEEauthorrefmark{3}Starfleet Academy, San Francisco, California 96678-2391\\
%Telephone: (800) 555--1212, Fax: (888) 555--1212}
%\IEEEauthorblockA{\IEEEauthorrefmark{4}Tyrell Inc., 123 Replicant Street, Los Angeles, California 90210--4321}}




% use for special paper notices
%\IEEEspecialpapernotice{(Invited Paper)}




% make the title area
\maketitle

\begin{abstract}
	Storage policy is difficult in federated cloud environments, since there are
	many cloud providers with distinct capabilities that should be addressed. In
	bioinformatics, many tools and databases requiring large resources for
	processing and storing enormous amounts of data, that can easily achieve
	terabytes of size, are provided by physically separate institutions. This
	article treats the problem of storage policy in ZooNimbus, a federated cloud
	infrastructure for bioinformatics applications. We propose a storage policy,
	named ZooClouS (ZooNimbus Cloud Storage), that is based on the latency, cost,
	uptime and free size to perform an efficient choice to distribute the files to
	the best resources available in the federated cloud to execute each required
	task.
	We developed experiments with real biological data executing on ZooNimbus,
	formed by some cloud providers executing in Amazon EC2 and UnB. The obtained
	results show that ZooClouS makes a significant improvement in the makespan time
	of bioinformatics applications executing in ZooNimbus, when compared to the
	random algorithm.
	
%	One of the biggest problems in a federated cloud infraestructure for
%	bioinformatics applications(ZooNimbus), is make a decision of where store the
%	files created by bioinformatics workflows, that can easily achieve Terabytes
	% of size, making a bottleneck when bioinformatics workflows process it. This work
%	aims to provide a storage policy for ZoooNimbus that we named ZooClouSP
%	(ZooNimbus Cloud Storage Policy), the policy  will improve a better and faster
%	way to transfer files between the nodes of the cloud and the clients, in a
%	simple way to facilitate the decision about where to store the files, due its
%	frequent occurence.
%	ZooClouSP consider latency as the main point to calculate the storage cost,
%	followed by cost per gigabytes' cloud, uptime's cloud  and free size's cloud,
%	doing a sorted list by the best costs. The initial tests appoint a significant
%	improvement for transfer workflows files created, improving the process of
%	bioinformatics workflows.
\end{abstract}
%\keywords{computing, storage, cloud federation}
%\begin{IEEEkeywords}
%component; formatting; style; styling;

%\end{IEEEkeywords}

% A federated cloud infraestructure for bioinformatics applications, called
% BioNimbus designed by H. V. Saldanha~\cite{hugo2012}, was developed to aim an
% architecture of a hybrid cloud federation, capable of running applications and
% bioinformatics workflows in a transparent, flexible, efficient and
% fault-tolerant manner, with high processing power and huge storage capacity.
% Was restructured, for address some news requests, like fast knowledge of peers
% connected in cloud, integrating ZooKeeper service and communication with 
% protocol RPC called Avro.
% For peer review papers, you can put extra information on the cover page as
% needed:
% \ifCLASSOPTIONpeerreview \begin{center} \bfseries EDICS Category: 3-BBND
% \end{center} \fi  For peerreview papers, this IEEEtran command inserts a page
% break and creates the second title. It will be ignored for other modes.
\IEEEpeerreviewmaketitle
\section{Introdução}
\label{sec:introdução}
Em um cen\'ario no qual a maior parte do processamento computacional \'e
realizado por servidores locais e {\it data centers} propriet\'arios, onde esse
poder de processamento computacional nem sempre é utilizado por completo,
paga-se por energia, manutenção e tecnologias que não são usadas em sua
totalidade~\cite{buyya2009}. Neste contexto, surgiu a ideia de que, em vez de se pagar
por uma estrutura proprietária, de manutenção cara, que as vezes fica ociosa, fosse
utilizada uma estrutura que use os seus recursos de acordo com a necessidade
de cada usuário. Assim, os recursos são alocados de acordo com a demanda de
utilização necessária, a chamada computação sob demanda. A grande vantagem da
computação sob demanda é que encerra o cenário onde o poder computacional
disponível acaba sendo desperdiçado por não ser utilizado em
sua totalidade~\cite{berkley2009}.

Nesse cenário, surge a plataforma de computação em nuvem, a qual busca reduzir o
custo computacional, aumentar a confiabilidade e a flexibilidade para
transformar computadores em algo no qual todo o tratamento dos dados e
aplicações são feitos como uma espécie de serviço básico~\cite{buyya2010}. O
objetivo é que a computação em nuvem disponibilize um serviço totalmente
sob demanda, em que para todos os processamentos solicitados, sejam alocados
recursos de acordo com a necessidade, e que esse processo seja totalmente dinâmico,
oferecendo poder computacional somente na medida necessária.

Atualmente, é possível encontrar alguns serviços de nuvens públicas por meio de
empresas como a Amazon~\cite{amazon2012}, a Microsoft~\cite{microsoft2012} e a
Google~\cite{googleappengine2013}. Em sistemas de
computação em nuvem, diferentes fundamentos estão presentes, tais como
virtualização, escalabilidade, interoperabilidade, qualidade de serviço (QoS),
mecanismo sobre falhas e modelos de entrega de nuvens (privadas, públicas e
híbridas). A estrutura de uma nuvem inclui diferentes partes envolvidas, com
atributos e tecnologias que são acopladas para atender suas necessidades e seus
diferentes tipos de serviços~\cite{rimal2009}. Os três principais
tipos de serviços de nuvens disponibilizados são os de software (SaaS),
infraestrutura (IaaS) e plataforma (PaaS) como serviços.

Como a quantidade de dados a ser processada aumenta cada vez mais no mundo
da computação, seja em processos de aplicações ou no próprio armazenamento de
dados, surge a necessidade de se ter um poder de processamento e armazenamento cada
vez maior, que possa atender pedidos em um tempo hábil, de modo automático e dinâmico.
Porém, uma nuvem possui recursos limitados e por conta disso surgiu a ideia de se
integrar nuvens com o objetivo de aumentar os recursos disponíveis, pois se um
recurso de uma nuvem se esgotar, uma outra nuvem pode utilizar os seus recursos
caso estejam disponíveis. Dessa ideia surgiu o conceito de federação de nuvens.

As federações de nuvens são conjuntos de nuvens que possuem todos os seus recursos
gerenciados por meio de uma interface conectada a todas elas, de forma que se
uma nuvem não tiver recursos para determinado processamento, uma outra nuvem que
esteja com recursos disponíveis no momento pode receber este processamento.

Assim sendo, a federação de nuvens tem se mostrado uma técnica capaz de integrar
diversas infraestruturas de nuvens, a qual proporciona a ilusão de que os
recursos da nuvem são ilimitados.

Nesse cenário, Hugo et al.~\cite{hugo2012} propôs uma arquitetura de
federação de nuvens chamada BioNimbus. O BioNimbus é uma arquitetura simples e
dinâmica que pode executar diferentes aplicações dentro da federação, atualmente
ela vem sendo utilizada para a execução de {\it workflows} de bioinformática.

O BioNimbus sofreu várias modificações na sua estrutura original, porém essas
alterações não mudaram os objetivos e as propostas iniciais da arquitetura de
federação em nuvens.
Entre os objetivos do BioNimbus estão integrar e controlar diferentes provedores
de infraestrutura, oferecendo um serviço flexível e tolerante a falhas, com suas
ferramentas de bioinformática. Integrando a arquitetura o ZooKeeper
Apache~\cite{zookeeper2010} e o Avro Apache~\cite{avro2012}, esta passou a ser
chamada ZooNimbus, apesar disso, ela continua a prover uma plataforma que
constrói uma federação em nuvem e que executa serviços de bioinformática com
recursos heterogêneos, públicos ou privados.

Porém, esta arquitetura não possui uma política de armazenamento de dados
definida.

Assim, o objetivo deste trabalho é propor uma política de armazenamento de dados
para a plataforma de federação ZooNimbus.
Para isso, este trabalho está dividido em seis Seções. A
Seção~\ref{sec:ZooKeeper} fala sobre as mudanças que ocorreram no ZooNimbus com
a integração do ZooKeeper Apache. A Seção~\ref{sec:avro} aborda as
alterações que ocorreram na comunicação do ZooNimbus com a integração do Avro
Apache. Na Seção~\ref{sec:zoonimbus} é mostrada como ficou a nova arquitetura do
ZooNimbus. A Seção~\ref{sec:politica} explica como funciona a política de
armazenamento de dados proposta neste artigo. Na
Seção~\ref{sec:resultados} estão os resultados obtidos com os testes feitos com
a implementação da política. E por último, na Seção~\ref{sec:conclusion}, estão
os trabalhos futuros que foram propostos para a melhoria da política e do
desempenho do ZooNimbus.


\section{ZooKeeper Apache}
\label{sec:ZooKeeper}
ZooKeeper~\cite{zookeeper2010} é um serviço de coordenação de dados, de
código-aberto para aplicações distribuídas.
ZooKeeper expõe um simples conjunto de primitivas que podem construir aplicações
distribuídas sobre a implementação de serviços de nível superior para a
sincronização, a manutenção, a configuração e os grupos.
Serviços de coordenação são notoriamente difíceis de serem precisos. Estes
serviços são propensos a erros, tais como condições de corrida e impasses.
Mesmo quando feito corretamente, diferentes implementações de serviços de
coordenação levam a complexidade de gestão, quando os aplicativos são
implantados. Neste contexto, o ZooKeeper visa facilitar as aplicações
distribuídas da responsabilidade de implementar serviços de coordenação a partir
do zero.
ZooKeeper foi projetado para armazenar dados de coordenação, informações de
{\it status}, configurações, informações de localização,
etc~\cite{zookeeper2010}.

Com relação aos seus dados, o ZooKeeper utiliza o termo {\it znode}, que são
usados para chamar nós de dados ZooKeeper, eles são estruturas de dados
semelhantes a diretórios.
Os dados armazenados em cada {\it znode} são lidos e escritos atomicamente.
Operações de leitura obtêm todos os {\it bytes} de dados associados a um {\it
znode} e uma operação de gravação substitui todos os dados. Cada nó tem uma lista de
controle de acesso (ACL), que restringe quem pode fazer o que com cada {\it
znode}. O ZooKeeper tem também a noção de {\it znodes} efêmeros. Estes {\it
znodes} existem enquanto a sessão que criou o {\it znode} está ativa. Quando a
sessão termina o {\it znode} é excluído.

Outro conceito do ZooKeeper é o suporte a {\it watches}, que são avisos. Os
servidores podem definir um {\it watcher} em um {\it znode}. Um {\it watcher} será
acionado e removido quando ocorrerem mudanças no {\it znode}. Quando um {\it
watcher} é disparado o cliente recebe um pacote dizendo que o {\it znode} mudou.
E se a conexão entre o cliente e um dos servidores ZooKeeper cair, o cliente
receberá uma notificação ({\it watcher}) avisando que o servidor caiu.

O ZooKeeper Apache foi integrado à plataforma de federação de nuvens ZooNimbus
para fornecer uma nova forma de trocar informações entre os servidores e
clientes.
Com o ZooKeeper, as funções P2P presentes no ZooNimbus foram substituídas pela
centralização e coordenação oferecida com os seus recursos.

Com a integração do ZooKeeper, todos os servidores do ZooNimbus consultam dados
referentes aos outros servidores dentro do próprio ZooKeeper. Dessa forma, toda
vez que um servidor é iniciado dentro da federação, é criado um {\it znode} com
seus principais dados dentro do ZooKeeper, assim sendo, quem for consultar ou
atualizar dados dos servidores, fará estas operações dentro do próprio
ZooKeeper. Na política de armazenamento proposta, vários dados são obtidos a
partir de um {\it znode} no ZooKeeper para o cálculo do custo de armazenamento
de um servidor e também para o tratamento dos arquivos.

\section{Avro Apache}
\label{sec:avro}
Avro Apache~\cite{avro2012} é um sistema de serialização de dados e de
chamadas remotas de procedimentos (RPC - {\it Remote Procedure
Call})~\cite{rpc} desenvolvido dentro do projeto Hadoop~\cite{hadoop} da
Apache. Ele é um sistema que oferece:
\begin{itemize}
  \item Estrutura de dados rica;
  \item Formato compacto e rápido de dados binários;
  \item Um {\it container} de arquivos para armazenar dados persistentes;
  \item Chamada remota de procedimentos (RPC - {\it Remote Procedure Call}~\cite{rpc});
  \item Integração simples com linguagens dinâmicas. Não é necessária a geração de
  código para ler e escrever arquivos de dados, nem para usar ou implementar
  protocolos RPC. Geração de código funciona como uma opção de otimização, só
  vale a pena implementar para linguagens de tipagem estática.
\end{itemize}
Quando os dados do Avro são lidos, o esboço utilizado na escrita deles estão
sempre presentes com os dados. Isso permite que cada dado escrito não tenha
despesas de valor, tornando a serialização de dados rápida e pequena, pois os
dados, juntos com os seus esboços, são totalmente auto-explicativos,
isto facilita o uso de linguagens de {\it script} dinâmicas.
Quando os dados Avro são armazenados em um arquivo, seu esboço é armazenado
junto com ele, de forma que os arquivos possam ser processados por qualquer
outro programa futuramente. Se o programa de leitura dos dados espera um esboço
diferente, isso pode ser facilmente resolvido, uma vez que ambos os esboços
estão presentes.

Quando o Avro é usado em RPC, o cliente e o servidor usam trocas de esboços de
dados quando uma conexão é estabelecida. Uma vez que o cliente e o servidor têm
esboços do outro, a correspondência entre os mesmos campos nomeados, campos em
falta, campos extras, etc, podem ser facilmente resolvidas.

Logo, esboços Avro são definidos com JSON~\cite{json}. Isso facilita a
implementação em linguagens que já possuem bibliotecas JSON,
anteriormente, a comunicação entre servidores e clientes no ZooNimbus
era realizada por meio de mensagens que eram enviadas pela arquitetura de rede
P2P. Esta forma de comunicação foi substituída pelas chamadas RPC do Avro, pois
com a comunicação feita com P2P, era necessário um broadcast, para descobrir os
computadores envolvidos na rede e a mensagem era enviada para todos, ja com o
RPC a mensagem é direta para o computador destino.

Dessa forma, o Avro fornece uma interface de
comunicação mais simples e robusta ao ZooNimbus. Como o Avro é um programa que
trabalha com recursos de rede para gerar e mandar as RPC. O Avro gerou classes
dentro do ZooNimbus que implementam os métodos que são chamados remotamente,
tanto por clientes quanto por servidores.

\section{ZooNimbus}
\label{sec:zoonimbus}
Inicialmente, proposta por Saldanha~\cite{hugo2012} a arquitetura ZooNimbus para
federação de nuvens computacionais híbridas, permite a integração e o
controle de diferentes provedores de infraestrutura, com suas ferramentas de
bioinformática oferecidas como serviço, de maneira transparente, flexível e
tolerante a falhas, com grande capacidade de processamento e armazenamento.
Neste contexto, procura-se oferecer a ilusão de que os recursos computacionais
disponíveis são ilimitados e que as demandas dos usuários sempre serão
atendidas.

Para atingir esses objetivos, a arquitetura ZooNimbus permite a integração de
diferentes plataformas de computação em nuvem, o que significa que provedores
independentes, heterogêneos, privados ou públicos de nuvens computacionais
podem oferecer seus serviços de bioinformática conjuntamente, mantendo suas
características e políticas internas. 

Para isso, a arquitetura do ZooNimbus é dividida em 3 camadas, conforme mostrada
na Figura~\ref{fig:zoonimbus}. A camada de infraestrutura possui as nuvens que
são integradas a arquitetura, devido a facilidade e dinamismo que o ZooNimbus
oferece, a qualquer momento uma nuvem pode ser integrada ou retirada da
federação. A camada núcleo possui os serviços do ZooNimbus atualmente
com seis componentes, onde cada um oferece um serviço independente do outro,
fazendo com que as funcionalidades de cada um sejam bem distintas.

\begin{figure}
	\centering
	\includegraphics[width=8cm, height=9cm]{imagens/zoonimbus.jpg}\\
	\caption{Arquitetura de Federação em Nuvens ZooNimbus.}
	\label{fig:zoonimbus}
\end{figure}

O serviço de
monitoramento é responsável por acompanhar a situação de cada servidor da
federação. Junto com o ZooKeeper, o serviço de monitoramento avisa todos os
servidores quando um dado é alterado em um {\it znode} e também quando um servidor
se desconectou da federação. Todos estes avisos são feitos através dos {\it watches}.
O serviço de segurança faz com que a integração de nuvens ocorra com a segurança
estabelecida de acessos, e que isso seja realizado de acordo com os requisitos e
políticas internas de todos os componentes da nuvem integrada. Serviço de descobrimento realiza a
rotina de descoberta da existência e da indisponibilidade de servidores por meio
do ZooKeeper. Como o
ZooKeeper utiliza os {\it watches} para notificar a indisponibilidade de um
servidor, não tem necessidade do serviço de descobrimento realizar verificações
de indisponibilidade. O serviço de escalonamento realiza o controle de execução
das tarefas no ZooNimbus, para isto, é utilizada uma política de escalonamento
para distribuir essas tarefas entre os servidores. A tolerância a falhas está
presente em todos os serviços do ZooNimbus, o que favorece o seu
desempenho e garante um maior sucesso na instalação da tolerância a falhas.

O serviço de armazenamento realiza o controle da recuperação e do envio dos
dados para a federação, para isto é utilizada a política proposta por este
trabalho, ZooClouS ({\it ZooNimbus Cloud Storage}), explicada na
Seção~\ref{sec:politica}.

\section{\it A Política de Armazenamento ZooClouS}
\label{sec:politica}
O ZooNimbus, não de forma exclusiva, tem sido usado para executar robustas
aplicações de bioinformática. Essas aplicações de um modo geral possuem
características semelhantes, as principais são:
\begin{itemize}
  \item Um conjunto de arquivos de entrada que serão analisados por uma ferramenta, que
podem ser originados a partir da saída da máquina de sequenciamento ou de outra
ferramenta de bioinformática;
\item Um conjunto de arquivos de saída contendo o resultado da análise realizada pela
ferramenta;
\item Um conjunto de parâmetros de execução que podem influenciar, por exemplo,
na utilização dos recursos de hardware ou no formato dos arquivos de entrada e de
saída.
\end{itemize}	

Estas aplicações podem executar rapidamente se o arquivo de entrada estiver na
nuvem que irá realizar o processamento, portanto, uma política que faça com que
este arquivo esteja sempre no servidor requisitante melhoraria o desempenho da
aplicação. Para melhorar este cenário foi implementada a política de
armazenamento de dados ZooClouS. 

O ZooClouS realiza vários serviços dentro do ZooNimbus, além de melhorar o
desempenho das aplicações, também realiza um controle na forma
em que os dados entram, saem e são replicados dentro da federação de nuvens.

Para facilitar o controle dos dados armazenados, o ZooClouS realiza as suas
operações em conjunto com o ZooKeeper utilizando os seus {\it znodes}. Cada
servidor que se conecta a federação recebe um identificador único (ID). Após isso, é
criado um {\it znode} no ZooKeeper com este ID. Dentro deste {\it znode} é
criado o {\it znode} {\it STATUS}, onde sua função é informar para o serviço de
monitoramento qual a situação daquele servidor. Quando um servidor se desconecta
da federação, o {\it znode} {\it STATUS} é mudado para {\it STATUSWAITING}, isso
mostra para o serviço de monitoramento que as rotinas de tolerância a falhas
devem iniciar imediatamente para aquele servidor.

O outro {\it znode} criado é o {\it files}, nele são criados outros {\it
znodes} filhos que correspondem aos arquivos que um servidor possui. Para cada
arquivo é criado um {\it znode} com os seus dados (ID, nome,
tamanho e uma {\it pluginList}). A {\it pluginList} é uma lista de
todos os servidores que possuem este arquivo, pois o serviço de armazenamento
replica todos os dados inseridos na federação. Este processo é mostrado na
Seção~\ref{subsec:zooclous}.

Além destes, também é criado o {\it znode} {\it pending save}, que recebe dados
de um arquivo que deverá ser enviado para a federação. A função da {\it pending
save} é avisar para todos os servidores que um arquivo deve ser inserido em
algum servidor.
Para cada arquivo que se deseja enviar a federação, é criado um {\it znode} dele na
{\it pending save} conforme mostra a Figura~\ref{fig:storage}, este {\it znode} é apagado
somente depois que o arquivo foi enviado para algum servidor e foi verificado
que ele chegou com sucesso.

\begin{figure}
		\centering
		\includegraphics[width=8cm, height=6cm]{imagens/zookeeper-storage.jpg}
		\caption{Estrutura do ZooKeeper no ZooNimbus com Relação ao Serviço de
		Armazenamento.}
		\label{fig:storage}
\end{figure}

Com a implementação do ZooClouS, um cálculo de custo de armazenamento foi
proposto, e com os resultados deste cálculo é possível escolher o servidor
que possui o menor custo de armazenamento para receber o arquivo que foi
solicitado o envio.

\subsection{O Cálculo do Custo de Armazenamento}
\label{subsec:calculo}
Assim sendo, quando um arquivo é enviado para a federação de nuvens ou replicado
dentro dela, um custo de armazenamento é calculado para aquele arquivo. Este
valor é gerado de forma transparente entre o cliente que requisitou a operação
de {\it upload} e cada servidor que tiver espaço em disco suficiente para
armazenar o arquivo. Para o ZooNimbus, foram utilizadas três variáveis para o
cálculo do custo de armazenamento:

\begin{itemize}
\item {\it Free Size}: espaço livre em disco do servidor; 
\item {\it Uptime}: tempo que o servidor está {\it on-line} na federação, um
servidor que está a mais tempo {\it on-line} mostra-se mais confiável de receber
o arquivo em comparação a outro que está a menos tempo, por ter se desconectado
ou por ter se conectado a federação a pouco tempo.
O tempo {\it on-line} tem um peso maior que o espaço livre no cálculo do custo.
Assim, toda vez que um servidor é desconectado da federação, o valor do {\it
uptime} é zerado e a contagem inicia novamente quando ele se reconecta na
federação, baseado nos artigos que demonstram que o servidor que for confiável,
se manterá confiável, mesmo que o uptime seja zerado, ou seja, o uptime será
zerado, mas ao passar do tempo o mesmo irá permanecer online, diferenciando
assim dos servidores que caem constantemente~\cite{maymounkov2002}.
\item {\it Latency}: latência entre o cliente e o servidor de destino, é o maior
peso no cálculo do custo.
\end{itemize}

Logo, a partir dos dados coletados, o cálculo do custo de armazenamento foi
criado baseado na proposta de Ren-Xun~\cite{xun2010}, onde o custo total de
armazenamento de um arquivo provém do custo de transferir somado com o custo de
armazenar determinado arquivo. ZooClouS coleta dados necessários para o cálculo
do custo de armazenamento dos servidores e define em cada servidor a variável
{\it storagecost}, que será o seu custo de armazenamento de um arquivo de acordo
com o cliente que realizou a requisição de envio. Cada cliente pega uma lista
dos servidores para calcular e setar o custo, isto evita que um custo seja
sobrescrito por outro cliente antes de ser utilizado pelo cliente anterior.
Dessa forma, o custo de armazenamento utilizado na política é uma forma
aproximada de definir o tempo de transferência entre dois servidores.
Quanto menor o valor, menor será o custo gasto na transferência do arquivo.
As três variáveis utilizadas para o cálculo do custo de armazenamento dão origem
a Equação~\ref{equation:storagecost}:

\begin{equation}
\label{equation:storagecost}
S = \frac{1}{((U + F)} * L
\end{equation}
Onde S é o custo de armazenamento, U é o tempo que o servidor está {\it on-line}
({\it uptime}), F é o espaço livre ({\it free size}) em disco, e L é a latência
calculada entre origem e destino. O objetivo é selecionar o menor custo
possível, quanto maior o {\it uptime} e o {\it free size}, menos custoso será
enviar o arquivo para este servidor, por conta disto, seus valores são somados e
esta soma divide 1, fazendo com que a fração seja resulte em um valor baixo
quando a soma for alta.
Após os valores serem fracionados e calculados, eles são multiplicados pelo
pelo valor da latência.

Além disso, as variáveis utilizadas possuem pesos com o objetivo de priorizar os
campos mais importantes no cálculo, assim tem-se a Equação~\ref{equation:pesos}:
\begin{equation}
\label{equation:pesos}
\alpha + \beta + \gamma = 1.0
\end{equation}
Com base em vários testes feitos, os valores dos pesos que definiram um melhor
custo de armazenamento foram definidos de tal forma que, $\alpha$ com um peso de
0.5 é associado à latência, colocando metade do peso do cálculo nela, $\beta$
com um peso de 0.2 e é associado ao {\it freesize}, e o $\gamma$ é atribuido ao
{\it uptime} e possui um peso de 0.3, Conforme mostrado na
Equação~\ref{equation:costwithweight}:
\begin{equation}
\label{equation:costwithweight}
S = \frac{1}{((U * \gamma + F * \beta)} * (L * \alpha)
\end{equation}
Esse cálculo forma a primeira parte do custo de armazenamento.
Todavia, como o ZooNimbus trabalha com nuvens públicas ou privadas, pode
acontecer de uma nuvem ser integrada à federação e ela cobrar um preço pela
utilização de seu recurso de armazenamento. Por conta disto, é necessário
adicionar ao custo de armazenamento o preço de armazenar um dado em uma nuvem
que faça cobrança. No caso de nuvens que, geralmente, pertencem a uma
organização privada ou instituição pública e que não cobrem valores para a utilização de seu
disco, o preço do seu armazenamento é 0.
Para outros casos, como por exemplo, a Amazon~\cite{amazon2012} ou
Azure~\cite{microsoft2012}, um valor é cobrado por {\it gigabyte} de dado armazenado.
Este valor, definido em dólares por {\it gigabyte} e é inserido no arquivo de
configuração da nuvem.

Com o valor do preço de armazenagem definido, este custo, representado pela
variável {\it costs}, é somado ao custo de armazenamento calculado daquela
nuvem, dando origem a Equação~\ref{equation:final}:
\begin{equation}
\label{equation:final}
S = \frac{1}{((U * \gamma + F * \beta)} * (L * \alpha) + Costs
\end{equation}
Depois de calculado o custo final de cada servidor, uma lista é recebida com
todos os servidores e ordenada de acordo com os seus custos de armazenamento. A
ordenação é feita em ordem decrescente, ou seja, do servidor que tem o menor
custo até o maior, sendo que quanto menor o custo, melhor será a transferência
de um arquivo para este servidor.
Após devolver esta lista para quem está requisitando um envio de {\it upload}, o
cliente irá tentar enviar o arquivo ao primeiro da lista, caso não consiga,
continuará tentando o envio no próximo servidor até que o arquivo seja enviado.
Além do {\it upload}, outros serviços foram implementados pela política de
armazenamento, ZooClouS, estes são explicados na Seção~\ref{subsec:zooclous}.

\subsection{Os Serviços do ZooClouS}
\label{subsec:zooclous}
Com o objetivo de otimizar o controle dos dados e o seu tratamento dentro de um
ambiente de federação de nuvens, o ZooClouS conta com vários serviços:
\begin{itemize}
  \item Listagem: lista todos os arquivos encontrados na federação, por meio de
  um único comando o cliente consegue visualizar todos os arquivos que estão
  salvos no ZooNimbus. Estes arquivos são mostrados em forma de uma única lista,
  dando para o usuário a ilusão de que todos estes arquivos estão armazenados
  somente no servidor que ele está conectado;
  \item {\it Download}: {\it download} de arquivos para o computador do cliente
  ou para o servidor que precisar de um arquivo para a execução de uma tarefa. Nesse caso,
  tanto o {\it download} quanto o {\it upload} são realizados por meio do
  protocolo SFTP~\cite{sftp}; 
  \item Replicação de todos os arquivos contidos na federação:
  toda vez que um novo arquivo é enviado ou gerado no ZooNimbus, o ZooClouS
  verifica quantas cópias existem daquele arquivo armazenadas na federação. Caso
  o número de cópias seja menor que o valor definido, o arquivo será
  replicado até atingir o número de cópias, definido no arquivo de configuração.
  Por padrão estão definidos duas cópias, mas esse valor é facilmente alterado.
  \item Tolerância a falhas: problemas na rede ou de energia são inevitáveis e
  pode acontecer de um servidor se desconectar do ZooNimbus, caso isto ocorra,
  todos os servidores da federação irão receber um aviso através do ZooKeeper,
  informando que um servidor está inacessível. A partir deste momento tem
  inicio a rotina de tolerância a falhas, que irá no {\it znode} do servidor que
  se desconectou e irá pegar informações sobre os arquivos que se tornaram
  inacessíveis. Com estas informações, o ZooClouS irá saber quais servidores
  possuem uma cópia de cada arquivo que estava no servidor que se desconectou.
  Assim uma mensagem é enviada
  para estes servidores avisando que eles devem replicar os arquivos, pois com a
  queda do servidor no ZooNimbus, possuem no momento uma cópia a menos. Assim, cada
  servidor que fizer realizar a replicação realiza um cálculo de custo de
  armazenamento entre ele e todos os outros servidores da federação e então inicia a
  replicação dos arquivos para o servidor escolhido.
\end{itemize}
 
\begin{figure}
	\centering 
\includegraphics[width=8cm,height=8cm]{imagens/avro.jpg}\\
	\caption{Chamadas RPC Passo-a-Passo.}
	\label{fig:avro_rpc}
\end{figure}

A Figura~\ref{fig:avro_rpc} mostra, de forma simples, como ocorre a
utilização do Avro no ZooNimbus no caso de uma operação de {\it upload}. Como
mostrado na Figura~\ref{fig:avro_rpc} (1) o cliente faz uma conexão com um
servidor na federação e (2) recebe uma lista com os servidores disponíveis para
receber o arquivo, (3) depois o cliente calcula a latência entre ele e os
servidores e envia uma chamada RPC para o servidor em que ele está conectado com
os dados que ele gerou e que serão utilizados no cálculo da política de
armazenamento. Após esse servidor receber os dados, decide qual o melhor
servidor para colocar o arquivo com base nos cálculos da ZooClouS a ser descrito
no próximo capítulo, (4) e faz uma chamada RPC para este servidor com os dados
do arquivo que o cliente pretende enviar para o ZooNimbus.
Após isso, (5) o cliente abre uma conexão com o servidor de destino e envia o
arquivo.
Todo o processo de cálculo da política e do destino do arquivo é detalhado na
Seção~\ref{sec:politica}.

\section{Análise de Resultados}
\label{sec:resultados}

Para os testes da política de armazenamento ZooClouS, foi
criada uma federação com três nuvens, as quais são:
\begin{itemize}
  \item Uma nuvem na Universidade de Brasília, com um processador Core i7-3770
  de 3,4 GHz, memória RAM de 8Gb, 2TB de disco rígido, com o sistema operacional
  Linux, distribuição Ubuntu 13.04. Essa nuvem está fisicamente localizada no Brasil;
  \item Uma nuvem na Microsoft Azure~\cite{microsoft2012}, máquina virtual com 8
  núcleos, 14Gb de RAM e disco rígido de 30Gb. Sistema operacional Linux,
  distribuição Ubuntu 12.04 LTS. A nuvem está localizada na Ásia Oriental; 
  \item Uma nuvem na Amazon~\cite{amazon2012},
  máquina virtual com processador Intel Xeon 2.4 Ghz, 613MB de memória RAM,
  disco rígido de 80GB e sistema operacional Linux, distribuição Ubuntu 12.04.2.
  A nuvem está localizada nos EUA.
\end{itemize}

O teste consistiu em realizar uma operação de {\it upload} para esta federação
com o cliente localizado no Brasil, o arquivo utilizado possui 70{\it Megabytes}
de tamanho, do tipo binário.
Foram feitos nove {\it uploads} de forma aleatória e nove com a política de
armazenamento ZooClouS. A forma aleatória é a forma como o BioNimbus realiza
operações de {\it upload}. Ele recebia a requisição e enviava o arquivo para o
primeiro servidor que encontrava, a escolha deste servidor não possuía nenhum
tipo de critério, o servidor era escolhido aleatoriamente, desta forma qualquer
servidor poderia ser escolhido para receber o arquivo.
\begin{figure}
		\centering
		\includegraphics[width=7cm, height=3cm]{imagens/escolhadestino.jpg}
		\caption{Destino de Arquivo Enviado ao ZooNimbus com a Implementação do
		ZooClouS, e sem a implementação do ZooClouS.}
		\label{fig:escolhadestino}
\end{figure}
Conforme mostrado na Figura~\ref{fig:escolhadestino}, com o ZooClouS,
observou-se que em 67\% dos envios, o arquivo foi enviado para a nuvem
localizada no Brasil. Com a política de armazenamento aleatória, 56\% dos envios
resultaram na nuvem localizada na Ásia. Isso demonstra que o ZooClouS, com base
no cálculo feito, envia o arquivo para o servidor que estiver mais próximo do
cliente, pois a latência é menor quando a origem e o destino estão mais próximos
geograficamente. Como a política considera a latência como fator mais
importante, o resultado do tratamento é o envio do arquivo ao servidor mais
próximo possível do cliente.
\begin{figure}
		\centering
		\includegraphics[width=8cm, height=5cm]{imagens/tempomedio.jpg}
		\caption{Tempo Médio de Transferência de Arquivo ao ZooNimbus com a
		Implementação do ZooClouS, e sem a Implementação do ZooClouS.}
		\label{fig:tempomedio}
\end{figure}
Assim, com a escolha do servidor de destino mais próximo do cliente, a transferência de
dados torna-se mais rápida, conforme mostra a Figura~\ref{fig:tempomedio}. A
taxa de transferência média foi calculada com base no tempo médio de
transferência do arquivo nas nove operações realizadas em cada algoritmo. Com a
implementação do ZooClouS, o tempo de transferência foi minimizado em cerca de
65\%. Observa-se que o tempo médio de transferência para o arquivo foi de 33,34
segundos com o ZooClouS, contra 51,23 segundos da forma aleatória do BioNimbus.
\section{Conclusão}
\label{sec:conclusion}
Neste trabalho foi proposto o ZooClouS, uma política de armazenamento de dados
para a arquitetura de fede\-ração em nuvens ZooNimbus. A política ZooClouS buscou
realizar um tratamento nos dados armazenados na arquitetura de forma a otimizar
o seu desempenho na execução de tarefas e {\it workflows}. Com base nos testes
realizados, concluiu-se que o envio de arquivos a federação de nuvens ZooNimbus
está ocorrendo de forma menos custosa ao cliente e ao servidor. Com as operações
de replicação e tolerância a falhas implementadas, a disponibilidade dos dados
aumentaram e também a obtenção de arquivos pelo cliente e pelo servidor, com a
operação de {\it download}.

Como trabalhos futuros, propõe-se a implementação de uma lista de
controle de acesso (ACL) para ser associada aos arquivos inseridos na federação,
de modo que somente usuários autorizados possam utilizar e modificar tais arquivos.
Além disso, propõe-se uma implementação do protocolo P-FTP ({\it Parallelized
File Transfer Protocol})~\cite{pftp2003} para um ambiente de federação em
nuvens, de forma a aumentar a velocidade na transferência de dados entre os
clientes e os servidores.

%\section{Introduction}
% no \IEEEPARstart
%This demo file is intended to serve as a ``starter file''
%for IEEE conference papers produced under \LaTeX\ using
%IEEEtran.cls version 1.7 and later.

%All manuscripts must be in English. These guidelines include complete
% descriptions of the fonts, spacing, and related information for producing your proceedings manuscripts. Please follow them and if you have any questions, direct them to the production editor in charge of your proceedings at Conference Publishing Services (CPS): Phone +1 (714) 821-8380 or Fax +1 (714) 761-1784.
% You must have at least 2 lines in the paragraph with the drop letter
% (should never be an issue)

%\subsection{Subsection Heading Here}
%Subsection text here.


%\subsubsection{Subsubsection Heading Here}
%Subsubsection text here.

%\section{Type style and Fonts}
%Wherever Times is specified, Times Roman or Times New Roman may be used. If
% neither is available on your system, please use the font closest in appearance to Times. Avoid using bit-mapped fonts if possible. True-Type 1 or Open Type fonts are preferred. Please embed symbol fonts, as well, for math, etc.


% An example of a floating figure using the graphicx package.
% Note that \label must occur AFTER (or within) \caption.
% For figures, \caption should occur after the \includegraphics.
% Note that IEEEtran v1.7 and later has special internal code that
% is designed to preserve the operation of \label within \caption
% even when the captionsoff option is in effect. However, because
% of issues like this, it may be the safest practice to put all your
% \label just after \caption rather than within \caption{}.
%
% Reminder: the "draftcls" or "draftclsnofoot", not "draft", class
% option should be used if it is desired that the figures are to be
% displayed while in draft mode.
%
%\begin{figure}[!t]
%\centering
%\includegraphics[width=2.5in]{myfigure}
% where an .eps filename suffix will be assumed under latex, 
% and a .pdf suffix will be assumed for pdflatex; or what has been declared
% via \DeclareGraphicsExtensions.
%\caption{Simulation Results}
%\label{fig_sim}
%\end{figure}

% Note that IEEE typically puts floats only at the top, even when this
% results in a large percentage of a column being occupied by floats.


% An example of a double column floating figure using two subfigures.
% (The subfig.sty package must be loaded for this to work.)
% The subfigure \label commands are set within each subfloat command, the
% \label for the overall figure must come after \caption.
% \hfil must be used as a separator to get equal spacing.
% The subfigure.sty package works much the same way, except \subfigure is
% used instead of \subfloat.
%
%\begin{figure*}[!t]
%\centerline{\subfloat[Case I]\includegraphics[width=2.5in]{subfigcase1}%
%\label{fig_first_case}}
%\hfil
%\subfloat[Case II]{\includegraphics[width=2.5in]{subfigcase2}%
%\label{fig_second_case}}}
%\caption{Simulation results}
%\label{fig_sim}
%\end{figure*}
%
% Note that often IEEE papers with subfigures do not employ subfigure
% captions (using the optional argument to \subfloat), but instead will
% reference/describe all of them (a), (b), etc., within the main caption.


% An example of a floating table. Note that, for IEEE style tables, the 
% \caption command should come BEFORE the table. Table text will default to
% \footnotesize as IEEE normally uses this smaller font for tables.
% The \label must come after \caption as always.
%
%\begin{table}[!t]
%% increase table row spacing, adjust to taste
%\renewcommand{\arraystretch}{1.3}
% if using array.sty, it might be a good idea to tweak the value of
% \extrarowheight as needed to properly center the text within the cells
%\caption{An Example of a Table}
%\label{table_example}
%\centering
%% Some packages, such as MDW tools, offer better commands for making tables
%% than the plain LaTeX2e tabular which is used here.
%\begin{tabular}{|c||c|}
%\hline
%One & Two\\
%\hline
%Three & Four\\
%\hline
%\end{tabular}
%\end{table}


% Note that IEEE does not put floats in the very first column - or typically
% anywhere on the first page for that matter. Also, in-text middle ("here")
% positioning is not used. Most IEEE journals/conferences use top floats
% exclusively. Note that, LaTeX2e, unlike IEEE journals/conferences, places
% footnotes above bottom floats. This can be corrected via the \fnbelowfloat
% command of the stfloats package.



%\section{Conclusion}
%The conclusion goes here. this is more of the conclusion

% conference papers do not normally have an appendix


% use section* for acknowledgement
%\section*{Acknowledgment}


%The authors would like to thank...
%more thanks here


% trigger a \newpage just before the given reference
% number - used to balance the columns on the last page
% adjust value as needed - may need to be readjusted if
% the document is modified later
%\IEEEtriggeratref{8}
% The "triggered" command can be changed if desired:
%\IEEEtriggercmd{\enlargethispage{-5in}}

% references section

% can use a bibliography generated by BibTeX as a .bbl file
% BibTeX documentation can be easily obtained at:
% http://www.ctan.org/tex-archive/biblio/bibtex/contrib/doc/
% The IEEEtran BibTeX style support page is at:
% http://www.michaelshell.org/tex/ieeetran/bibtex/
%\bibliographystyle{IEEEtran}
% argument is your BibTeX string definitions and bibliography database(s)
%\bibliography{IEEEabrv,../bib/paper}
%
% <OR> manually copy in the resultant .bbl file
% set second argument of \begin to the number of references
% (used to reserve space for the reference number labels box)
%\begin{thebibliography}{1}

%\bibitem{IEEEhowto:kopka}
%H.~Kopka and P.~W. Daly, \emph{A Guide to \LaTeX}, 3rd~ed.\hskip 1em plus
%  0.5em minus 0.4em\relax Harlow, England: Addison-Wesley, 1999.
  
%\bibitem{hugo2012}
%H.~V.~Saldanha. Bionimbus: uma arquitetura de federa\c{c}\~ao 
%de nuvens computacionais h\'ibrida para a execu\c{c}\~ao de workflows de
% Bioinform\'atica.
%Master's thesis, Departamento de Ciência de Computação, Universidade de
%Brasília, 2012.

%\end{thebibliography}

  \bibliographystyle{plain}%apalike
  \bibliography{artigobibliografia}


% that's all folks
\end{document}


